UML

核⼼元素之参与者

参与者（

actor

）在建模过程中是处于核⼼地位的。

UML

官⽅⽂档对

actor

的定义为：参与者（

actor

）是在系统之外与系统交互的某⼈或

某事物。

“

系统之外

”

的定义说明在参与者和系统之间有⼀个明显的边界，参与者（

actor

）只可能存在于边界之外，边界之内的所有⼈或者事

物都不是参与者。

参与者（

actor

）还有另外⼀种叫法：主⾓。主⾓这⼀叫法则很明确的说明了只有主动启动了业务的，才是参与者。

发现参与者

⾸先了解⼀个概念：涉众（

stakeholder

），也称为⼲系⼈。涉众是与要建设的这个系统有利益相关的⼀切⼈和事，涉众的利益要求会影

响系统的建设。参与者的⼀个重要来源是涉众，从涉众中找出那些直接对系统发出动作，或者直接从系统中接受反馈的涉众。参与者是涉众

代表，参与者对系统的要求直接影响系统的建设，他们的要求就是系统需求的来源，参与者通过对系统提出要求来获得他所代表的涉众的利

益。参与者的另⼀个来源是客户的岗位设置。

在查找参与者的过程中，尝试寻找⼀下问题的答案有助于你确定参与者：

1

、谁负责提供、使⽤或者删除信息？

2

、谁将使⽤此功能？

3

、谁对某个特定功能感兴趣？

4

、在组织中的什么地⽅使⽤系统？

5

、谁负责⽀持和维护系统？

6

、系统有那些外部资源？

7

、其他还有那些系统将需要与该系统进⾏交互？

参与者⼀定是直接并且主动向系统发出动作并获得反馈的，否则就不是参与者。

业务主⾓（business actor）

业务主⾓是参与者的⼀个版型，特别⽤于定义业务的参与者，在需求阶段使⽤。业务主⾓是与业务系统有着交互的⼈和事物，他们⽤来

确定业务范围。业务主⾓的特殊性在于，它针对的是业务⼈员⽽⾮计算机⽤户。要建设⼀个符合客户需要的计算机系统，⾸要条件是完全彻

底地搞清楚客户的业务，⽽不是预想已经有了⼀个计算机系统，再让客户来假设需要计算机系统帮助他们完成什么。

所以在初始需求阶段，请务必使⽤业务主⾓，时时牢记业务主⾓是客户实际业务⾥的参与者，没有计算机系统，没有抽象的计算机⾓

⾊。业务主⾓必须在实际的业务⾥能找到对应的岗位或⼈员。

业务⼯⼈（business worker）

   在建模过程中，有些⼈员虽然参与了业务，但是⾝份很尴尬，因为他们是被动参与业务的，不好确定其⽬的是什么，但是⼜确确实实在业

务过程中做了事情。出现这种困扰的原因是打破了对边界的定义，这样的⼈员实际上应该是边界内的⼈员，被称为业务⼯⼈（business

worker）。

如何区分参与者和业务⼯⼈呢？最直接的⽅法是判断他是出现在系统边界之内还是在边界之外。如果边界不清楚，可以通过以下三个问题

来澄清。

、

他是主动向系统发出动作的吗？

、

他有完整的业务⽬标吗？

、

系统是为他服务的吗？

如果以上三个问题的答案都是否定的，那么他⼀定是业务⼯⼈。

参与者与⽤户和⾓⾊的关系

⽤户（

user

）是指系统的使⽤者，通俗⼀点说就是系统的操作员。⽤户是参与者的代表，或者说是参与者的实例或者代理。并⾮所有参

与者都是⽤户，但是⼀个参与者可以代理多个参与者。

⾓⾊（

role

）是参与者的职责。⾓⾊是⼀个抽象概念，从众多参与者的职责中抽象出来相同的那⼀部分，将其命名为⾓⾊。⼀个⾓⾊代

表了系统中的⼀类职责。

参与者的核⼼地位

参与者是涉众的代表，它代表涉众对系统的利益要求，并向系统提出建设要求；参与者通过代理给其他⽤户或者将⾃⾝实例化成为⽤户

来使⽤系统；参与者的职责可以⽤⾓⾊来归纳，⽤户被指定扮演哪个或哪些⾓⾊因此来获得参与者的职责。

同时，系统是以参与者的观点来决定的。参与者对系统的要求对系统的表述完全决定了系统的功能。